home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.19941031-19941221 / 000457_news@columbia.edu_Fri Dec 16 13:48:52 1994.msg < prev    next >
Internet Message Format  |  1995-07-31  |  4KB

  1. Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA01165
  2.   (5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 16 Dec 1994 23:30:21 -0500
  3. Received: by apakabar.cc.columbia.edu id AA19182
  4.   (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 16 Dec 1994 23:30:18 -0500
  5. Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!cs.utexas.edu!news.cs.utah.edu!cc.usu.edu!jrd
  6. From: jrd@cc.usu.edu (Joe Doupnik)
  7. Newsgroups: comp.protocols.kermit.misc
  8. Subject: Re: MS-Kermit running under Windows trbl
  9. Message-Id: <1994Dec16.194852.35622@cc.usu.edu>
  10. Date: 16 Dec 94 19:48:52 MDT
  11. References: <D0wsAs.6vv@nntpa.cb.att.com>
  12. Organization: Utah State University
  13. Lines: 57
  14. Apparently-To: kermit.misc@watsun.cc.columbia.edu
  15.  
  16. In article <D0wsAs.6vv@nntpa.cb.att.com>, mrbaker@hodcs.ho.att.com (-M.BAKER) writes:
  17. > Hi:
  18. > We are currently using MS-Kermit (Beta 14) to communicate with a UNIX
  19. > system, both directly from the DOS prompt as well as run from Windows.
  20. > I have packet driver 3C5X9PD and shim WINPKT doing the networking
  21. > honors.
  22. > The problem is that when someone telnet's to the UNIX system from
  23. > Windows (i.e., they have an icon for MS-KERMIT, using the .PIF
  24. > distributed with MS-KERMIT) everything works fine until they minimize
  25. > it and leave it alone for a while [still trying to measure exactly what
  26. > "a while" is -- seems to be a half hour or hour or so].  Then when they
  27. > return to MS-KERMIT, it is 'asleep'.  The TCP-IP connection no longer
  28. > seems to be working (no response to the UNIX shell prompt, no response
  29. > to the Telnet Are-You-There) yet the UNIX system still thinks the
  30. > connection is up.  I've tried running with SET TELNET DEBUG-OPTIONS ON
  31. > looking for clues, but no luck.
  32. > The only mentions I could find in the documentation is in the .BWR file.
  33. > Section 4 (Microsoft Windows) suggests changing the .PIF to raise
  34. > Kermit's priority, lock it in memory (even though the WINPKT docs
  35. > say this shouldn't be necessary), and make sure some background time
  36. > is allocated.  I've played with these the best I could with no apparent
  37. > luck.  It does have the caveat that Kermit is at the mercy of other
  38. > apps. anyhow.
  39. > When I run MS-Kermit right from DOS (no Windows), it works just fine
  40. > even overnight so I'm pretty sure the indigestion is coming from Windows.
  41. > Would appreciate hearing from others who have run into this, have ideas,
  42. > etc. worth trying in order to minimize (if not eliminate) this problem.
  43. > Private email to mrbaker @ hodcs.att.com, or postings to this group
  44. > would be most welcome.
  45. --------------
  46.     Ok. I tried your situation here over the past 45 minutes. MSK 3.14
  47. beta-15 running in Windows as an icon, using ODIPKT+WINPKT over the current
  48. Novell ODI material. I logged onto my Unix machine with Kermit, shrunk MSK
  49. to an icon, and went away to speak with WordPerfect/Windows for the duration.
  50. After that 45 minute interval I enlarged the icon to a window and the
  51. connection was just fine.
  52.     A couple of guesses to make here. First, is your lan adapter's
  53. shared memory protected against all memory managers (DOS and again in
  54. Windows)? If not then Windows could be using that memory for other purposes
  55. and the lan adapter can become wedged or worse. An intermediate test, after
  56. you've exclude='d both sides, is to start another Telnet session with Kermit.
  57. If a new session starts ok then local comms are in working order.
  58.     Second, the lan adpater part of things may not be especially strong
  59. to begin with, and when it's not serviced often packets overwhelm it and it
  60. wedges. If there is an IRQ conflict (lan adapter sitting on IRQ 3 along with
  61. serial port COM2, for example) then the adapter can be squashed by the
  62. competing hardware and/or Window's drivers.
  63.     The option to "fix task in memory" is needed if you are not using
  64. winpkt with a Packet Driver. Go get mine, the two argument variety, from
  65. netlab2.usu.edu, cd drivers, file winpkt.zip, and give it a try. I don't fix 
  66. tasks in memory (absent minded Professor).
  67.     Joe D.